QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/tcp/940134.txt

Internet Message Format | 1994-11-13 | 15KB

Date: Thu, 30 Jun 94 04:30:07 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #134
To: tcp-group-digest


TCP-Group Digest            Thu, 30 Jun 94       Volume 94 : Issue  134

Today's Topics:
                       How about a new NOS KIT?
                  Non-TCP/IP Related Radio for Sale
                       NOS and the PC (3 msgs)
                Why not a solid PBBS program? (2 msgs)

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Wed, 29 Jun 1994 16:12:55 -0400 (EDT)
From: DJ Gregor <[e-mail]>
Subject: How about a new NOS KIT?
To: [e-mail]

In the July '94 "Packet Perspective" in QST, Stan Horzepa, the column's author,
mentioned that he distributed a plug 'n' play Macintosh TCP/IP package, and
asked if there is such a package for MS-DOS.

I have seen Dave Fritsche's (wb8zxu) nos_kit package, but it is over four years
old.  Is there a newer NOS KIT package?  If not, let's get together and make
one, and make it available.


-----
DJ Gregor, N8QLB
[e-mail]

------------------------------

Date: Wed, 29 Jun 94 13:36:31 CDT
From: [e-mail] (System Administrator)
Subject: Non-TCP/IP Related Radio for Sale
To: [e-mail]

I have 3 800 mHz Trunked HT's for sale. They have MDC/CTCSS/DTMF
Keypad/100 memoriesetc. They are the Uniden 800FPTS...1 for $100, or 3
for $250..all include rapid chargers/batteries. E-mail at
[e-mail] for more info

Also, TCP/I Related!
I'm lookin for a good base/mobile rig to use on TCP/IP to setup a
Conference @ Chicago. However, I lack a rig for this use. My Icom 22S
which I was originally going to use died on me.
If anyne has a radio they're willing to let me borrow/they wanna
donate/sell (for extremly cheep!) E-mail me at [e-mail]

Farewell,
N9TOL - Greg Kaiser

------------------------------

Date: Wed, 29 Jun 1994 13:14:22 +0100
From: Adrian Godwin <[e-mail]>
Subject: NOS and the PC
To: [e-mail]

> Not being an expert I can only relate what I have heard and that is
> that DMA, although it sounds great does not always give the results
> you would expect. Many of the cards perform better, on fast processors,
> in polled mode.
>

All the PC ethernet cards I know of do DMA from the ethernet controller
to on-board memory. The differences appear when you transfer the ethernet
packet from the card's memory to the PC's memory (and in the other direction).
This can be done in one of 3 ways :

  Memory transfer :
  The ethernet card's mempory is visible in the PC's expansion space.
  A loop of code copies each byte (or word, on a 16-bit card) from the
  expansion area to main memory. Speed is limited by the I/O bus cycle
  time, and the processor's time to execute the loop.
  The WD8003 cards do this.

  e.g. while(length--)
    *memory++ = *card_buffer++;


  Programmed I/O :
  This is what's been described as polled, though I tend to reserve that term
  for systems where the CPU has to wait for a byte to be ready before copying.
  In fact, it's very similar to a memory transfer (and runs at similar speed).
  The difference is that the read from the card is performed at a single
  I/O location, and the transfer position within card memory is maintained by
  logic on the card. This saves expansion bus memory space.
  The NE1000 cards do this.

  e.g. while(length--)
    *memory++ = input(data_port);


  DMA :
  The PC's DMA controller is used to perform the transfer. The DMA controller
  performs a sequence of memory writes (using internal counters), but
  simultaneously drives signals to the card which act rather like an I/O read
  and provide a single byte in each operation. This halves the number of
  bus cycles used for the transfer, and requires no overhead from the CPU.
  However, the PC's DMA controller runs at 4MHz, so the actual transfer takes
  a lot longer (albeit at reduced system load) than if the CPU were to do
  the job, especially if the PC has an I/O system that can run at faster
  than the specified 8MHz. Also, DMA on the PC is a scarce resource, and
  may not run in 16 bit mode (not sure about that one).
  The NE1000 cards can do this, but the Crynwr packet driver uses programmed I/O.

  Disclaimer : I don't much like PCs, and have avoided becoming an expert on
  them. I might have made some or all of the above up, but I believe it until
  someone corrects me.

-adrian

------------------------------

Date: Wed, 29 Jun 94 02:42:00 -0000
From: [e-mail] (Mike Bilow)
Subject: NOS and the PC
To: [e-mail]

Cc: [e-mail]
Cc: [e-mail]

 DC>   You keep using the term "serial I/O" - actually it is parallel I/O
 DC> 8 or 16 bits from the ethernet card to the processor buss. The term
 DC> Polled I/O vs DMA can be applied to this connected Parallel I/O port.
 DC> In other words how is the data retrieved - direct to memory or handled
 DC> by the processor in a polled fashion.

There are generally two architectures for Ethernet cards.  The NE2000 style
pulls an IRQ to signal that it has a buffer of data, usually a frame, but up to
16 or 32 KB.  This is very efficient, especially from protected mode, because
the processor can loop on I/O instructions rapidly, while it does very few
context switches forced by the IRQ signal; as a result, this is ofter called
"polled I/O" although that is not strictly true.  This is contrasted with the
usual serial port architecture where there is an IRQ pull and the resulting
full context switch on each received byte.

The other major design for an Ethernet card is the memory mapped style, where
the 16 or 32 KB buffer appears in the processor address space.  The card will
still usually pull an IRQ line to signal that it needs attention, but the data
will then be moved from the card to main memory using very fast
memory-to-memory instructions.  The disadvantage to this is that some very
fancy footwork is required to do this kind of thing on a 386 or better
processor in protected mode.

 DC> Not being an expert I can only relate what I have heard and that is
 DC> that DMA, although it sounds great does not always give the results
 DC> you would expect. Many of the cards perform better, on fast processors,
 DC> in polled mode.

DMA is not particularly useful for Ethernet cards.  It tends to be slower than
the other methods when the motherboard DMA controller is used, and it requires
extensive management and set up by the drivers.  DMA in protected mode is a
truly hellish thing.

-- Mike

------------------------------

Date: Wed, 29 Jun 94 18:22:00 -0000
From: [e-mail] (Mike Bilow)
Subject: NOS and the PC
To: [e-mail]

Cc: [e-mail]

In a msg on <Jun 29 12:14>, Adrian Godwin writes:

 AG> All the PC ethernet cards I know of do DMA from the ethernet
 AG> controller to on-board memory.

Yes, but even we techno-dweebs in this group have limits to what we will
actually worry about.  The main issue is how the Ethernet card as a whole
interfaces to the machine bus.

 AG> However, the PC's DMA controller runs at
 AG> 4MHz, so the actual transfer takes   a lot longer (albeit at
 AG> reduced system load) than if the CPU were to do   the job,
 AG> especially if the PC has an I/O system that can run at
 AG> faster   than the specified 8MHz.

The worst problem with DMA in the modern 386 world is that the machine address
space can be mapped into physical memory such that the translation changes from
time to time.  In some cases, such as with Unix or OS/2, memory pages may
actually be not present, which has very bad effects on DMA.

 AG> Also, DMA on the PC is a
 AG> scarce resource, and   may not run in 16 bit mode (not sure
 AG> about that one).

No, in a 286 or better, DMA channels 0-3 are 8-bit and 4-7 are 16-bit.  Some of
these are used for dedicated purposes, however.  DMA channels are a scarce
resource, somewhat like IRQs.

-- Mike

------------------------------

Date: Wed, 29 Jun 94 10:29:00 EDT
From: "Battles, Brian" <[e-mail]>
Subject: Why not a solid PBBS program?
To: TCP-Group <[e-mail]>

DJ Gregor, N8QLB ([e-mail]) said:

> I've been thinking of something like this. If everyone could get together
and write a
> good Amateur Radio PBBS program for Linux-- **NOT** a JNOS port or
something
> like that, one that operates like a UNIX shell--we could then strip down
the Linux
> kernel, and integrate everything. Make it easy to configure and use--for
the
> *AVERAGE* PBBS operator, like the ones that run MSYS now. If we do that,
we'd have
> a NICE and POWERFUL PBBS that would run on an 80386 with 4 megabytes of
memory.
> Most MSYS operators I've seen have that kind of system already.

  Yeah, I have a similar question. I'm not a programmer, so I apologize for
not being able to offer to do much to assist with such a project, but why
isn't there a good, solid, NOS-based PBBS package available for hams who run
DOS, Windows or OS/2 machines? Jeez, there's so much "old-style" (non-NOS)
software out there (eg, W0RLI,  WA4RE, MSYS, FBBS, etc), but so many people
who want the considerable advantages of TCP/IP have such a hard time (A)
Finding a version/compile that *works*, and (B) Struggling to get it
configured so that it's compatible with the larger "world" of the AX.25 PBBS
network.

  I know it can be done because a few people are doing it now, but a
complete, stable "friendly" NOS PBBS package might be what it takes to get
some SysOps into TCP/IP and off MSYS, W0RLI, FBBS, etc. As it stands, it
sure seems much easier to set up an MSYS PBBS, and adding TCP/IP
compatibility (SMTP, etc) is awfully tricky (I always hear NOS people saying
that MSYS's SMTP stuff is "broken," etc).

  Perhaps it would take a commercial venture to do it right. Would a PBBS
SysOp, who's spent maybe $1000-$2000 (or more) on radios, TNCs, antennas,
PCs, etc, also shell out maybe $50-$100 or so for GOOD software that beats
the heck out of the standard freebie AX.25 PBBS packages or the bazillion
semi-complete NOSs floating around?

  Not to push for a greed-driven motive for working on better software
solutions in Amateur Radio, but sometimes money can bring qualified people
with their best efforts out of the woodwork!

  Something to think about...

CUL es 73 de BB
 ___________________________________________________________________________
 Brian Battles, WS1O  I  Internet     [e-mail]  I  "Radio amateurs
 QST Features Editor  I  Compu$erve   70007,3373         I   do it with high
 ARRL HQ              I  MCI Mail     215-5052           I      frequency"
 Newington, CT USA    I
 Tel [phone]     I  Amprnet      [e-mail] [44.88.2.43]
 Fax [phone]     I  AX.25 packet WS1O @ W1EDH.CT.USA.NA
 BBS 203-666-0578     I

    =--> Sometimes you have to look reality in the eye and deny it. <--=
 ___________________________________________________________________________
      COMMENTS EXPRESSED HEREIN ARE MY OWN PRIVATE, PERSONAL REMARKS
     AND ARE TOO INANE TO BE CONSIDERED OFFICIAL ARRL VIEWS OR POLICY.

------------------------------

Date: Wed, 29 Jun 94 23:07 EDT
From: [e-mail] (Gary L. Grebus)
Subject: Why not a solid PBBS program?
To: [e-mail]

>but why
>isn't there a good, solid, NOS-based PBBS package available for hams who run
>DOS, Windows or OS/2 machines? Jeez, there's so much "old-style" (non-NOS)
>software out there (eg, W0RLI,  WA4RE, MSYS, FBBS, etc), but so many people
>who want the considerable advantages of TCP/IP have such a hard time (A)
>Finding a version/compile that *works*, and (B) Struggling to get it
>configured so that it's compatible with the larger "world" of the AX.25 PBBS
>network.

I have some suspicions, but first let me ask a question.  What are the
"considerable advantages of TCP/IP" in the context of a PBBS?  If the
idea is to have users interacting with the standard PBBS interface,
then I suggest that adding TCP/IP has considerable disadvantages.  Use one
of the fine PBBS packages mentioned above.  If the idea is just to move
data between the PBBS network and the AMPRnet, then that argues for
minimal functionality.  Or even better, run a PBBS and and NOS and
interchange the data by filtering one set of files into another.

As to why people have a tough time making NOS be a good PBBS and a
good TCP/IP server:

-- Either task alone is enough to fill the 640K DOS limit.  (The expansion
   of PBBS function in NOS has come at the expense of TCP/IP features.)

-- Gatewaying between the internet mail/news world and the PBBS
   world is a hard problem.  Supporting both environments is much more
   than twice as hard.

-- TCP/IP and PBBS's use AX.25 in different ways.  Accomodating both
   adds complexity.


If people are really set on evolving NOS, then what is needed is
some  *management* of the effort.  Put the source code under a revision
control system, and make controlled checkins possible on the Internet.
Recruit a cadre of beta-testers whose use cover most of functionality
(protocols, hardware, servers, compilers, etc) and application (PBBS,
router, TCP server).  Since customization is by re-compiling, automate
test builds of various combinations of features and compiler
versions.  Mandate documentation checkins along with new
functionality.  Etc.

The technology exists to do large, distributed software projects.  But
an ad-hoc approach is going to produce ad-hoc results, and the long
term value of NOS is going to diminish.

And with any luck, I'll be able to compile out all the stuff I don't
need,  get the latest and greatest of what I do need, and have it all
be stable.

73,

    /gary
    K8LT

Gary L. Grebus        Home:  [e-mail]  (decvax!balrog!glg)
Brookline, NH           Work:  [e-mail]
            Ham Packet: K8LT@WA1PHY.#EMA.MA.USA
"Stamp out the PBBS in our lifetime."

------------------------------

End of TCP-Group Digest V94 #134
******************************